Skip to content

Change default inventory key to E, default Aux1 key to F #16053

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

minlemon
Copy link
Contributor

To do

This PR is Ready for Review.

  • Check there are no other places the default keybinding for inventory, Aux1 is specified
  • After merging: update docs page /for-players/controls/

How to test

Launch a new game that uses inventory and Aux1 (e.g. VoxeLibre). Press E for inventory. Hold F to run.

@y5nw y5nw added the UI/UX label Apr 21, 2025
@Zughy Zughy added Feature ✨ PRs that add or enhance a feature Roadmap: Needs approval The change is not part of the current roadmap and needs to be approved by coredevs beforehand labels Apr 21, 2025
@sfan5 sfan5 self-requested a review April 22, 2025 08:18
@lhofhansl
Copy link
Contributor

IMHO... why change the default? If folks want to change it, they have the option.

@minlemon
Copy link
Contributor Author

IMHO... why change the default? If folks want to change it, they have the option.

Please review the discussion in #16052. The short answer is that the default inventory key of "I" cannot be pressed without looking down at the keyboard and Luanti should come with solid defaults. As a case study Minecraft started with inventory key being "I" but switched to "E" after user feedback.

@sfan5 sfan5 added this to the 5.12.0 milestone Apr 26, 2025
@sfan5
Copy link
Collaborator

sfan5 commented Apr 26, 2025

Adding to milestone, because I think we should decide this before release.

Copy link
Collaborator

@sfan5 sfan5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works. I support this.

@sfan5 sfan5 added One approval ✅ ◻️ and removed Roadmap: Needs approval The change is not part of the current roadmap and needs to be approved by coredevs beforehand labels May 2, 2025
@Zughy
Copy link
Contributor

Zughy commented May 2, 2025

👎

I'm the owner of a mini-game server, featuring 10 different mini-games. Here are some stats:

  • only 1 mini-game out of 10 features and uses the inventory (skywars). Pressing "I" outside skywars won't even show an inventory
  • 3 mini-games out of 10 + the lobby use AUX1 for specific actions. These being:
    • Block League - renders the scoreboard whilst held down
    • Fantasy Brawl - same as above
    • Sumo - sprints
    • Lobby - displays all the people online and some info about them (ping, role, what they're playing) whilst held down
  • the aforementioned mini-games display graphics telling you what key does what
  • Block League is the most played mini-game (last 30 days)
    image
  • it's one of the most played servers out there

Given these points, changing the key is a breaking change for us: although it'll result in a better UX for skywars (faster inventory access), it'll worsen the UX of the rest (PC players got used for years to press E, starting from myself), also forcing us to update the graphics that display controls. And to be clear: we don't care that much about skywars compared to our original mini-games, it's only there as a soft landing for people coming from Minecraft.

We're already using sub-optimal keys, as all I need to get confused and hit the wrong key is to play some FPS to then come back to Block League (an FPS on Luanti), where the reloading key isn't R but Q (drop key) because of LT limitations. What I'd like to see, on the contrary, is the possibility for modders to be able to map whatever key they need for their games. I don't want the scoreboard on E, but I don't even want it on F, having to rewire my brain after 4 years of pressing E. I'd want it where every game puts it, so as to create a continuum between my game and the others: on TAB. That would fix my problem. This, on the contrary, is only another layer of annoyance.

Considering the embarassing bikeshedding on retrocompatibility other people and I had to face in the past, even when it made little to no sense, seeing core devs now happy to change a key because a lot of games will benefit from it even if some others will experience a drawback is frankly ridiculous. Is my game less important than others? Where's the retrocompatibility now? Would you code the required changes for me? Display different graphics according to the client version, let alone the fact that I now need to get used to F?

To be clear: I'm super happy if people playing games featuring inventories can have a better UX, but I expect this to happen without worsening the experience of other games not caring about inventories. I think this should come alongside the possibility for modders to associate whatever key to whatever action. As it is, as a modder of something that doesn't want to be like Minecraft, I oppose it.

@minlemon
Copy link
Contributor Author

minlemon commented May 2, 2025

@Zughy I understand the sentiment, just remember that existing players would not have to "rewire their brains" since their existing local controls settings won't change. This is primarily targeted to new players and a general best-by-default UX improvement which should make Luanti in general more attractive and prevent early frustration in playing using the engine (like my friend and I experienced). You mention that you have a game as a soft landing from people coming from Minecraft - we should ensure those new players continue to come.

I completely agree that there should be per-game controls and mod-suggested keyboard defaults. You can view this PR as a stepping stone toward greater acceptance of similar changes. Once I implement encryption over Luanti's networking stack I would be happy to help you work on a per-game controls feature. I don't want to get this PR held up however because I very strongly feel it is necessary from a new player perspective.

@Zughy
Copy link
Contributor

Zughy commented May 2, 2025

just remember that existing players would not have to "rewire their brains" since their existing local controls settings won't change

Right now modders have no way to get the key associated to the action. Meaning that if there is a HUD telling that Action A = AUX1, the default might be E or F according to the client version (and you'll either write E or F, "AUX1" doesn't make sense to the average player). So if our HUDs are already broken for mobile users and people with custom keybinding, now they'll always be broken even for PC players depending on LT version because we had to pick whether to stick to E or F. Unless, which is more coding, we display two different texts by checking the version. It'd be fine if this were going in the right direction, but it's not: when/if all the keys become available like in a real engine, we'll need to change the code again (hardcoded AUX1 (E, F) or TAB). No, thanks.

Once I implement encryption over Luanti's networking stack I would be happy to help you work on a per-game controls feature

Then let's plan this for 5.13, in 3 months, alongside what I've requested*, so games like mine don't have to be punished for the "greater good". Air quotes because I'd like to remind that my server was the only one being featured twice in a row at FOSDEM at the Luanti booth, so again, we're not talking about a niche game with a couple of users per day. I expect Luanti not to complicate the life of those games that actually make it more popular, especially if those games did nothing wrong. Moreover, last time I checked we wanted to be as much detached as possible from being a Minecraft clone, yet this move only makes life easier for Minecraft clones, potentially worsening it for games that are not interested in being one.

*It's obvious that in order to do that, we need to have a clear direction and not just merge whatever we want. But this is a horse of a different colour

@sfan5

This comment was marked as resolved.

@NathanSalapat
Copy link
Contributor

I agree with Zughy, this change will make any existing tutorials/videos confusing to new users as they will have the old inventory/Aux 1 key being used. If new players are having such trouble finding the inventory key it sounds like we should do a better job exposing the keys to new users, and letting them know that they can change them to whatever they'd like.

@minlemon
Copy link
Contributor Author

minlemon commented May 2, 2025

@NathanSalapat This is not an issue with finding the inventory key. The point of the PR is that the I key is not a very good default for inventory. It is not reachable with your left hand while playing a game, forcing you to look down at the keyboard in order to press it - in fact, you should not have to "find" the key at all. Instead it should be in an ergonomic location so you don't have to take your eyes from the screen, like the E key. This is what Minecraft players discovered 14 years ago. As for existing tutorials/videos, those will age and be replaced regardless as Luanti continues to change and be developed further; if Luanti doesn't change much in the future, then the earlier we make this change, the better in that respect.

I kind of expected some resistance: Minecraft forums had some people who still preferred the I key shortly after the change to E in 2011. But just a year later there was a second discussion about key defaults and it appears that virtually nobody was changing it back to I because it simply makes sense design-wise to put a frequently used key next to the WASD keys in a WASD game and not on the other side of the keyboard.

@Zughy
Copy link
Contributor

Zughy commented May 2, 2025

Minecraft forums had some people who still preferred the I key shortly after the change to E in 2011. But just a year later there was a second discussion about key defaults and it appears that virtually nobody was changing it back to I

That makes totally sense, back then I was playing Minecraft using E as well. The issue here is that Minecraft was and still is a game. Here, on the contrary, we're talking about a gaming platform, which is different. We can't just ignore some games to benefit others

@sfan5
Copy link
Collaborator

sfan5 commented May 3, 2025

First I want to clarify one point:

just remember that existing players would not have to "rewire their brains" since their existing local controls settings won't change.

Changing the default will change it for everyone, except if they have explicitly set these keys in their config (e.g. by changing them at least once in the controls menu).
Keeping the old keys for all existing players is possible, but would have to be implemented as extra compatibility code.


it'll worsen the UX of the rest (PC players got used for years to press E, starting from myself)

This is true but largely unavoidable. If we think that I really is a bad place to put an often used key, that's more reason to do it soon as possible.
And obviously people can still customize their key bindings.

In the same breath as the dialog for #16049 we can even inform players that the keys have changed, provide convenient options
to keep the old layout, and more.

also forcing us to update the graphics that display controls

Keeping the default key bindings the same forever was never realistic, and you were relying on the peculiarity of Luanti using character-based keybindings instead of scancodes.
As of #14964 this has changed so that key that triggers AUX1 may or may not have E written on it.

In fact all QWERTZ users now need to press a totally different key to zoom. I do not see the same opposition to that change.
(Since we have some breaking key changes in 5.12 anyway this is why I suggested to consider this PR too.)

What I'd like to see, on the contrary, is the possibility for modders to be able to map whatever key they need for their games.

I agree. However, this is not what this PR is about.
Changing the default keys now does not impede having fully flexible key bindings in the future. It does not consume developer time that could have been spent on developing such a system.

If it was realistic to have flexible keys ready for 5.13 I could be convinced to hold off of this change, but we know this isn't the case.

seeing core devs now happy to change a key because a lot of games will benefit from it even if some others will experience a drawback is frankly ridiculous

Can you elaborate on why this is a drawback for certain games?
I can see you arguing why changing the key at all is harmful, but is there a game where the inventory is better left on I?

The whole premise of this PR is that I is an inconvenient placement for a common key, not that "Minecraft has the inventory on I so we should too".

Display different graphics according to the client version, [...]?

Don't you have this anyway to account for mobile players?

While it won't work with in-game graphics the proper solution to this is an escape sequence like hecks proposed some day that dynamically expands to whatever key AUX1 is bound to on each client.

@y5nw
Copy link
Contributor

y5nw commented May 3, 2025

just remember that existing players would not have to "rewire their brains" since their existing local controls settings won't change.

Changing the default will change it for everyone, except if they have explicitly set these keys in their config (e.g. by changing them at least once in the controls menu). Keeping the old keys for all existing players is possible, but would have to be implemented as extra compatibility code.

In addition to this, the old keybinding menu (before #15791; i.e., 5.11 and earlier ...) only saved keybindings that were different from the default value, and binding a key to its default clears the setting:

for (key_setting *k : key_settings) {
std::string default_key;
Settings::getLayer(SL_DEFAULTS)->getNoEx(k->setting_name, default_key);
if (k->key.sym() != default_key)
g_settings->set(k->setting_name, k->key.sym());
else
g_settings->remove(k->setting_name);
}

While it won't work with in-game graphics the proper solution to this is an inline-formatting like hecks proposed some day that dynamically expands to whatever key AUX1 is bound to on each client.

Related: #14788. Although I would instead prefer introducing an escape sequence that gets expanded client-side.

Also: graphical buttons are hard to get right while also allowing styling.


I can imagine that we merge this after addressing #14788, but given that said feature will not be implemented in the current release cycle I am not sure whether it is a good idea to break keybinding defaults in two consecutive releases instead of merging this PR into 5.12.

@Zughy
Copy link
Contributor

Zughy commented May 3, 2025

Keeping the default key bindings the same forever was never realistic, and you were relying on the peculiarity of Luanti using character-based keybindings instead of scancodes.

Which is fine if

  1. it's headed in the right direction (which, in our case, is E -> TAB). On the contrary, it's E -> F -> maybe one day TAB
  2. we have the possibility to know what key corresponds to what action (e.g. if I move the drop key to LCtrl, on my screen I'd like to read "LCtrl" in Fantasy Brawl instead of "Q" next to the skill triggered by the drop key). That's how it is now, just to be clear. Keys are hardcoded drawings

image

Inb4: "regarding this screen, how about mobile users?"
That would require the ability to add touch buttons to bind certain actions to the button (also removing the key drawing); something not feasible at the moment.

Can you elaborate on why this is a drawback for certain games?
I can see you arguing why changing the key at all is harmful, but is there a game where the inventory is better left on I?

I don't know, my whole point is that we don't care about the inventory because we don't feature it basically anywhere, making E/AUX1 a fundamental key for some games and the lobby. Now that the default gets moved to F, that means rewiring our brain. Which is fine if the rewiring meant a better key (which varies according to the game, hence the request for games to choose their mapping; in our case is TAB, except for Sumo, where F makes more sense), but it's not going in that direction. This PR makes life easier for games featuring inventories but it worsens it for games not caring about inventories and that use E/AUX1 as a key part of their gameplay

@SmallJoker
Copy link
Member

SmallJoker commented May 4, 2025

Could we perhaps settle this with a long-running poll on the forums? There's only a few people on GitHub, thus limited feedback.
I don't think this needs to be changed for 5.12.0. For most keyboard layouts (as in: languages), the I key will stay in the same spot even after the SDL2 scancode compatibility code that happened in 5.12.0-dev.

@SmallJoker SmallJoker added the User feedback needed Feedback from players/server owners/modders is needed to determine if the change should be done. label May 4, 2025
@sfan5
Copy link
Collaborator

sfan5 commented May 4, 2025

  1. it's headed in the right direction (which, in our case, is E -> TAB). On the contrary, it's E -> F -> maybe one day TAB

But we're not planning to change the Aux1 default again. The Tab key you want would only come with custom keybindings.

That's how it is now, just to be clear.

That's not how it is in 5.12-dev right now, to be clear.
Your graphic for Z is wrong for German-speaking countries as well as many eastern european ones (who need to press Y) and French-speaking ones (W)¹, not to mention custom layouts.
Q and E happen to almost always be on the same key position, and are unaffected (check Krock's link for details).
This was caused by #14964 and is not going away, because that's how scancodes work.

¹: AFAICT French users were never able to play Luanti on default settings because their WASD is ZQSD instead

Which is fine if the rewiring meant a better key (which varies according to the game, hence the request for games to choose their mapping; in our case is TAB, except for Sumo, where F makes more sense), but it's not going in that direction

I think I get it now. In short: You have a game that uses E and doesn't care about I, so for gameplay reasons it would be nicer if Aux1 remained on E.
Following that, we should not be messing with the defaults and instead work towards an ultimately better solution.
Right?

Could we perhaps settle this with a long-running poll on the forums?

Poll for what exactly?

  • I being inconvenient is fairly objective.
  • Putting the inventory on E can be argued about but whether we like it or not I think Minecraft doing this is a pretty big argument.
  • Where to put F can be discussed.

For most keyboard layouts (as in: languages), the I key will stay in the same spot even after the SDL2 scancode compatibility code that happened in 5.12.0-dev.

That is true, but this isn't my reason for proposing to do this change in 5.12.
The reasoning is that for many people this release will cause at least one noticeable key change, so it would be a good idea to merge it with another change (change fatigue).

@sfan5
Copy link
Collaborator

sfan5 commented May 4, 2025

As discussed in the meeting we would like consensus on the following question:

  • should any change to the default bindings be done now, or not?
  • (not necessarily the specific proposed change)

ping @luanti-org/engine

@Zughy
Copy link
Contributor

Zughy commented May 4, 2025

That's not how it is in 5.12-dev right now, to be clear

I was referring to the picture down below, as in "that's how the minigame currently looks like"

I think I get it now. In short: You have a game that uses E and doesn't care about I, so for gameplay reasons it would be nicer if Aux1 remained on E.

Exactly

@ryvnf
Copy link
Contributor

ryvnf commented May 5, 2025

Moreover, last time I checked we wanted to be as much detached as possible from being a Minecraft clone, yet this move only makes life easier for Minecraft clones, potentially worsening it for games that are not interested in being one.

I understand that Luanti wants to be a general platform. I do however find it odd that the fact that it "makes life easier for Minecraft clones" is presented as an argument against this. Luanti is a voxel game engine, and sandbox games will always be a big part of it (Minecraft clones or not). I do not see how deliberately avoiding changes because it benefits a certain type of game would be of any benefit to the project.

There are also a lot of non-sandbox games that have some form of inventory management. I searched online and found this reddit post which lists quite a few. The games listed span multiple different genres (in fact, most are not survival sandbox games). The inventory formspec in Luanti is also very general and does not have to be a traditional grid based inventory. FPS games can for example use it as an inventory screen to customize weapons.

The by far most popular non-sandbox Luanti game (by multiplayer activity) is also Capture the flag, which makes heavy use of the inventory key.

The default controls will always be a compromise. It does however make sense for the default controls to be somewhat optimized for the "average" Luanti game. It is an objective fact that the I key for inventory is bad for most games due to people not being able to press it consistently without looking down. I also think it is pretty clear that E makes most sense because it will be familiar with other popular games out there.

@Zughy
Copy link
Contributor

Zughy commented May 5, 2025

I do however find it odd that the fact that it "makes life easier for Minecraft clones" is presented as an argument against this

That's how the sentence you quoted continues: ", potentially worsening it for games that are not interested in being one". This conversation is already pretty hard to sustain, please don't add cherrypicking, thank you.

The by far most popular non-sandbox Luanti game (by multiplayer activity) is also Capture the flag, which makes heavy use of the inventory key.

So in your logic if I'm not the most popular server out there (even if I'm one of the most played nonetheless) my practical use case is irrelevant? What? What's next, discredit my server because in the end is not that great so we shouldn't care?

It does however make sense for the default controls to be somewhat optimized for the "average" Luanti game

Yet again: great. But I'm not the average Luanti game and I see no reason why after 5 years of server development and LT contributions I should be punished because I chose not to stick with the "average" Luanti game model. Give me the possibility to customise players' keybinding and everyone will be happy. You don't? Average games UX will be better, my server's will be worse - and that, I don't accept it. It's already frustrating having active skills on zoom, doing tricks with the pinkie every time, my users and I don't deserve to also get used to F. Dealing with keybindings in general is already pretty frustrating, as modders have few to work with and good UX to reach

@ryvnf
Copy link
Contributor

ryvnf commented May 5, 2025

That's how the sentence you quoted continues: ", potentially worsening it for games that are not interested in being one". This conversation is already pretty hard to sustain, please don't add cherrypicking, thank you.

I apologize if I focused too much on that phrasing. I see that my response mischaracterized what you said slightly and I take that back. I am the maintainer of a package that was implied in your comment so it felt a bit personal for me too.

The way I understood your argument was that (1) Luanti wants to be a general game platform; (2) this change primarily benefit survival sandbox games; and (3) it will be an inconvenient change for your game (perhaps others also). That together then implies that this change goes against the Luanti goal (1) and should not be made. This is the reasoning I disagree with. I do not think which games benefit most should have anything to do with it, as long as the change is good overall.

My argument was also that even if this change would likely benefit survival sandbox games more than other games, it will still benefit Luanti games as a whole. A lot of games have inventory management, and I is very unfriendly to all of them. Contrary to what you wrote when you said that this change "only makes life easier" for the type of game I am developing. Again, I may have focused a bit much on phrasing but I still think my comment raised good points and what I quoted was worth addressing.

So in your logic if I'm not the most popular server out there (even if I'm one of the most played nonetheless) my practical use case is irrelevant? What? What's next, discredit my server because in the end is not that great so we shouldn't care?

I am not discrediting your server. I respect that you are trying to create something different. My point is that when it comes to trade-offs like default controls, one should consider the "average" use case more than uncommon use cases. I do not think this should be controversial.

Yet again: great. But I'm not the average Luanti game and I see no reason why after 5 years of server development and LT contributions I should be punished because I chose not to stick with the "average" Luanti game model. Give me the possibility to customise players' keybinding and everyone will be happy. You don't? Average games UX will be better, my server's will be worse - and that, I don't accept it. It's already frustrating having active skills on zoom, doing tricks with the pinkie every time, my users and I don't deserve to also get used to F. Dealing with keybindings in general is already pretty frustrating, as modders have few to work with and good UX to reach

Again, I am sorry I offended you. That was not my intention. I value all your contributions to Luanti (both engine dev and game dev). That said, I have also been involved with Luanti for a long time and so have many others. Collectively across all individuals more effort has been spent on the games that will benefit from these changes than those which will be inconvenienced by it.

I have not played your minigames but I do not understand how moving E to F is a significant change (other than having to relearn). Both keys are reached with the same finger and is next to the key the finger normally rests on. It feels reasonable to assume that people will adapt to it, and people who do not want to relearn can simply remap aux1 to E.

Edit: I tested and realize F is a slightly longer reach because it goes sideways. It is still a minor change though, especially when compared to I to E.

@ryvnf
Copy link
Contributor

ryvnf commented May 5, 2025

I have previously suggested #16052 (comment) Ctrl for default Aux1 (what I personally use). That may be a better candidate, but considering it is a bigger change I can see people being more skeptical towards it.

@Zughy
Copy link
Contributor

Zughy commented May 5, 2025

@sfan5 I might have a solution here that would make everyone happy: add AUX2 as you previously suggested, where AUX2 is Tab by default (if enabled). I'd simply use AUX2 instead of AUX1, except for Sumo where F is supposed to make you go faster (so F makes sense, so AUX1). People like @ryvnf would have their inventory key closer and I would have the keybinding I was looking for since the beginning (TAB). Thoughts?

@ryvnf
Copy link
Contributor

ryvnf commented May 6, 2025

@sfan5 I might have a solution here that would make everyone happy: add AUX2 as you previously suggested, where AUX2 is Tab by default (if enabled). I'd simply use AUX2 instead of AUX1, except for Sumo where F is supposed to make you go faster (so F makes sense, so AUX1). People like @ryvnf would have their inventory key closer and I would have the keybinding I was looking for since the beginning (TAB). Thoughts?

Sounds good to me.

@sfan5
Copy link
Collaborator

sfan5 commented May 6, 2025

Thoughts?

@grorp pointed out that AUX2 is a problem for Android (or the touch GUI in general) because it needs to be bound to a button. However aux2 has no function on its own, so what should the symbol look like?

Edit: I guess I misunderstood it a bit. here's a quote instead:

00:12 <[MatrxMT]> <grorp> That's true. I'd say "let's do it", if it wasn't for my concern that if we add Aux2, we'll be stuck with that UX kludge forever due to backwards compat once games start using it.
00:13 <[MatrxMT]> <grorp> It would be another confusing, and in many situations useless, button in the touch controls, occupying valuable screen space. This would be acceptable for a temporary/short-term solution, but not if it has to stay. How can we get rid of it again once we have a proper solution?

@Zughy
Copy link
Contributor

Zughy commented May 6, 2025

Aux1 is just an icon saying "Aux1" so... "Aux2"?

It's ugly but It's coherent

@grorp
Copy link
Member

grorp commented May 7, 2025

Aux1 is just an icon saying "Aux1" so... "Aux2"?

It's ugly but It's coherent

That's what you would do, yes. But it doesn't solve the fundamental problem.
See the IRC logs for https://irc.luanti.org/luanti-dev/2025-04-22. (sfan5 quoted a part, but there are more messages that are relevant. Also there's two lonely related messages the next two days :)

@cx384
Copy link
Contributor

cx384 commented May 7, 2025

Since I got pinged by this PR, here are my personal thoughts, in case it matters, otherwise ignore it.

From my experience, I is more widely used than E to open the inventory in games. Especially in games where you move your character with the mouse instead of wasd. In those games, the keys qwer and 1234 are used to trigger something else.
I'm not too concerned about adopting the minecraft style to open the inventory using E. I'm more concerned about moving aux1 to F, since you need to hold it and W at the same time. With E this is very easy since it is next to W, but when I hold F and W at the same time I have to spread my fingers too much, which is uncomfortable. Also, for me, it is not a big problem that I have to move my fingers away from wasd to open the inventory, since I don't need it to move the player while the inventory is open. Maybe using tab or anything else near wasd (e.g. F, C, R, ...) (or above space like B or V) to open the inventory would be better.

@Zughy
Copy link
Contributor

Zughy commented May 7, 2025

Let's cut the chase: if core devs think this #11446 (comment) is a viable solution, I can offer €150 to accelerate the development, PayPal taxes on me. I'm tired of being limited to Zoom, Aux1 and Drop key

@ryvnf
Copy link
Contributor

ryvnf commented May 7, 2025

Let's cut the chase: if core devs think this #11446 (comment) is a viable solution, I can offer €150 to accelerate the development, PayPal taxes on me. I'm tired of being limited to Zoom, Aux1 and Drop key

I do not think a bounty changes things in a significant way. I still think the PR should be merged in the mean time. Merging it does not go against future fully customizable keybindings as it only changes defaults. Maybe if it were to add Aux2, but I do not think that is necessary.

To me #12488 is still very far away, even with a bounty. It requires a lot of changes and the introduction of a completely new set of APIs that need be fleshed out. From what I can tell (from discussion and SSCSM tag) the consensus is also that it should be implemented using SSCSMs which are currently not in place and becomes a blocker. That makes sense considering custom keybinds (like opening inventory) would otherwise be affected by server latency.

I also found a forum post from 2022 which lists good arguments for changing the defaults:

It proposes using E and F exactly like this PR. I think the fact that it has been independently suggested and the majority seemed to agree with the forum post suggests that it will be a positive change.

@rubenwardy
Copy link
Contributor

I don't think F is a good location for aux, it's an unusual location for both sprinting/fast and auxilliary actions. In most other games, they're separate keys with sprint being LShift or LCtrl and aux being E or a mouse button.

To avoid this endless debate, I'd recommend leaving this for now and certainly not changing it for 5.12.0, we've done this for many years and users can always rebind if the position annoys them. Once we have an actions API, we can turn aux1 into just a fast key at LShift and let mods define their own more specific control schemes.

@v-rob
Copy link
Contributor

v-rob commented May 7, 2025

I'm certain I've mentioned this before, but why does everyone seem to ignore the Q key? Maybe I'm an exception, but I almost never have a legitimate use for drop item, which makes it very strange to give it such prime real estate. I always rebind it to inventory instead and leave Aux1 at E.

To be clear, I also agree with not changing anything for 5.12.0.

@Zughy Zughy removed this from the 5.12.0 milestone May 7, 2025
@X-DE1
Copy link

X-DE1 commented May 24, 2025

Why not open the inventory with Tab instead of I, which is used in more games and allows you to close and open inventories with text fields?
Or make it so that when opening a formspec, the text field isn't selected. 🤪 😎 🤩🙈

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@ Client / Controls / Input Controversial Feature ✨ PRs that add or enhance a feature One approval ✅ ◻️ UI/UX User feedback needed Feedback from players/server owners/modders is needed to determine if the change should be done.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Default inventory key "I" should be changed to something more natural